1.3 긴 문맥(Long Context) 처리의 효율성 저하와 추론 속도 문제

거대언어모델(Large Language Models, LLM)의 발전사는 곧 문맥(Context) 확장의 역사와 궤를 같이한다. 초기 수천 토큰 수준에 불과했던 문맥 창(Context Window)은 GPT-4, Claude 3, Llama 3.1 등 최신 모델에 이르러 128K를 넘어 1M, 심지어 무한 문맥(Infinite Context)을 지향하며 급격히 확장되었다. 그러나 이러한 문맥 확장은 트랜스포머(Transformer) 아키텍처가 태생적으로 지닌 구조적 한계를 적나라하게 드러내는 계기가 되었다. 사용자와 모델이 주고받는 정보량이 기하급수적으로 증가함에 따라, 트랜스포머의 추론 엔진은 연산 복잡도와 메모리 대역폭이라는 두 가지 거대한 장벽에 직면하게 된다. 본 장에서는 트랜스포머 기반 모델이 긴 문맥을 처리할 때 발생하는 효율성 저하의 메커니즘을 알고리즘적 특성, 하드웨어 아키텍처, 그리고 경제적 비용의 관점에서 심층 분석하고, 왜 이것이 단순한 최적화의 문제를 넘어 새로운 아키텍처 패러다임을 요구하는 구조적 위기인지 논증한다.

1. 2차 복잡도(O(N^2))의 물리적 비용과 연산 자원의 불균형

트랜스포머 모델의 핵심 혁신이자 동시에 가장 큰 병목은 셀프 어텐션(Self-Attention) 메커니즘에 있다. 시퀀스 내의 모든 토큰이 서로를 참조하여 관계성을 학습하는 이 구조는 문맥 이해력을 비약적으로 높였으나, 그 대가로 시퀀스 길이 N에 대해 2차 함수(O(N^2))로 증가하는 연산 비용을 요구한다. 이는 문맥 길이가 짧을 때는 무시할 수 있는 수준이지만, 긴 문맥 시나리오에서는 시스템 전체를 마비시키는 주된 요인이 된다.1

1.1 어텐션 행렬 연산의 폭발적 증가와 하드웨어 부하

표준적인 어텐션 연산은 쿼리(Q), 키(K), 밸류(V) 행렬을 통해 수행되며, 그 핵심은 Q와 K^T의 행렬 곱(Dot Product)을 통해 N \times N 크기의 어텐션 스코어 행렬을 생성하는 과정이다. 이 과정에서 필요한 부동소수점 연산(FLOPs)의 수는 4N^2d (여기서 d는 헤드 차원)에 비례한다.3 시퀀스 길이가 2배 증가하면 연산량은 4배로 증가하며, 10배 증가하면 100배로 폭증한다. 예를 들어, 4,096(4K) 토큰을 처리할 때와 비교하여 128K 토큰을 처리할 경우, 입력 데이터의 양은 32배 늘어나지만, 어텐션 연산량은 32^2인 1,024배로 증가한다.

이러한 연산량의 비선형적 증가는 현대 GPU 하드웨어, 특히 NVIDIA A100이나 H100과 같은 고성능 가속기의 연산 파이프라인에 극심한 불균형을 초래한다.1 트랜스포머의 다른 구성 요소인 피드포워드 네트워크(FFN)나 레이어 정규화(Layer Normalization) 등은 시퀀스 길이에 대해 선형(O(N))으로 증가하는 연산량을 가지므로, 문맥이 길어질수록 전체 연산에서 어텐션이 차지하는 비중이 압도적으로 커지게 된다. 이는 “긴 문맥에서의 추론은 곧 어텐션 연산 그 자체“라는 말이 과장으로 들리지 않을 만큼, 시스템 자원의 대부분을 어텐션 스코어 계산에 쏟아붓게 만든다.

1.2 프리필(Prefill) 단계에서의 지연 시간(Latency) 급증

추론 과정은 크게 입력 프롬프트를 처리하는 ‘프리필(Prefill)’ 단계와 토큰을 하나씩 생성하는 ‘디코딩(Decode)’ 단계로 나뉜다. 2차 복잡도의 문제는 특히 프리필 단계에서 두드러진다. 사용자가 수만 토큰에 달하는 문서나 코드를 입력으로 제공할 경우, 모델은 첫 번째 토큰을 생성하기 전에 이 방대한 입력 전체에 대한 어텐션 관계를 계산해야 한다.

FlashAttention과 같은 최적화 기법은 GPU의 HBM(High Bandwidth Memory) 접근을 줄이고 SRAM(Static RAM) 내에서 타일링(Tiling) 방식으로 연산을 수행함으로써 메모리 대역폭 병목을 완화하고 연산 속도를 획기적으로 개선했다.4 그러나 FlashAttention조차도 O(N^2)라는 연산량의 절대적 총량을 줄여주지는 못한다. 즉, 메모리 입출력(I/O) 효율성을 극대화하여 연산 장치(Compute Unit)의 가동률을 높였을 뿐, 물리적으로 수행해야 할 곱셈과 덧셈의 횟수는 여전히 시퀀스 길이의 제곱에 비례한다. 따라서 문맥 길이가 100K, 1M 단위를 넘어서면 아무리 최적화된 커널을 사용하더라도 첫 토큰 생성 시간(Time To First Token, TTFT)은 필연적으로 지연될 수밖에 없다.1 사용자는 질문을 입력하고 답변이 시작될 때까지 수 초에서 수십 초를 기다려야 하며, 이는 실시간 상호작용이 필요한 애플리케이션에서 치명적인 사용자 경험 저하로 이어진다.

2. KV 캐시(KV Cache)의 팽창과 메모리 용량 장벽

연산 복잡도가 프리필 단계의 주요 병목이라면, 디코딩(Decoding) 단계에서의 효율성을 가로막는 가장 큰 장벽은 바로 메모리 용량, 구체적으로는 ’KV 캐시(Key-Value Cache)’의 비대해진 크기이다. 트랜스포머의 디코더는 자기회귀(Autoregressive) 특성을 가지므로, t번째 토큰을 생성하기 위해 1부터 t-1번째까지의 모든 토큰 정보를 다시 참조해야 한다. 매 단계마다 이를 재계산하는 낭비를 막기 위해 과거 토큰의 Key와 Value 벡터를 GPU 메모리에 저장해두는 것이 KV 캐시이다.7

2.1 선형 증가가 초래하는 비선형적 시스템 비용

수학적으로 KV 캐시의 크기는 시퀀스 길이 N에 선형 비례(O(N))한다. 얼핏 보면 O(N^2)인 어텐션 연산에 비해 착해 보이는 복잡도이지만, 실제 시스템 운용 관점에서는 훨씬 더 심각한 물리적 제약을 가한다. KV 캐시가 차지하는 메모리 용량(M_{KV})은 다음과 같이 계산된다.
M_{KV} = 2 \times P \times L \times H \times d_{head} \times N_{batch} \times N_{seq}
여기서 P는 정밀도(Byte), L은 레이어 수, H는 헤드 수, d_{head}는 헤드 차원, N_{batch}는 배치 크기, N_{seq}는 시퀀스 길이이다.

Llama-3-70B 모델을 예로 들어보자. 이 모델을 FP16 정밀도로 128K 문맥에서 구동한다고 가정하면, 단일 요청(Batch Size=1)만으로도 KV 캐시를 위해 수십 기가바이트(GB)의 VRAM이 필요하다. 모델 가중치 자체가 이미 약 140GB를 차지하는 상황에서, 긴 문맥을 위한 KV 캐시가 추가되면 단일 A100(80GB) 또는 H100(80GB) GPU로는 도저히 감당할 수 없는 메모리 요구량이 발생한다.9

이는 단순히 GPU를 더 많이 꽂아서 해결될 문제가 아니다. 모델 가중치와 KV 캐시를 여러 GPU에 분산 저장(Model Parallelism)하게 되면, 추론 과정에서 GPU 간 통신이 빈번하게 발생한다. 특히 KV 캐시가 분산되어 있을 경우, 어텐션 연산을 위해 각 GPU가 보유한 KV 데이터를 수집(All-Gather)하거나 결과를 합산(All-Reduce)하는 과정에서 막대한 통신 오버헤드가 발생하며, 이는 전체 추론 속도를 네트워크 대역폭 수준으로 끌어내린다.12

2.2 배치 크기(Batch Size) 축소와 처리량(Throughput)의 붕괴

서버 비용 효율성의 핵심 지표는 처리량(Throughput), 즉 단위 시간당 얼마나 많은 토큰을 생성해내느냐이다. GPU의 처리량을 극대화하려면 가능한 한 많은 요청을 하나의 배치(Batch)로 묶어 병렬 처리해야 한다. 그러나 긴 문맥 시나리오에서는 KV 캐시가 메모리를 독식하기 때문에 배치 크기를 키울 여력이 사라진다.

문맥 길이가 짧을 때는 수십, 수백 개의 요청을 동시에 처리할 수 있었던 GPU가, 128K 문맥에서는 단 하나의 요청(Batch Size=1)을 처리하기 위해 허덕이게 된다.8 배치 크기가 1로 줄어든다는 것은 GPU의 수천 개 코어 중 극히 일부만 사용된다는 것을 의미하며, 이는 값비싼 H100 GPU를 구매하여 1%의 성능만 사용하는 셈이 된다. 결과적으로 토큰당 생성 비용(Cost per Token)은 급격히 상승하고, 서비스 제공자는 경제적 타당성을 잃게 된다. 이는 기업들이 긴 문맥 모델을 서비스할 때 높은 가격을 책정하거나, 속도 제한을 엄격하게 두는 근본적인 이유이다.14

아래 표 1.3-1은 Llama-3-70B 모델 기준으로 문맥 길이에 따른 메모리 요구량과 배치 크기의 트레이드오프 관계를 보여준다.

표 1.3-1 문맥 길이에 따른 Llama-3-70B 모델의 KV 캐시 메모리 요구량 및 최대 배치 크기 (추정치)

9

표에서 볼 수 있듯이, 128K 이상의 문맥에서는 배치 크기가 극도로 제한되며, 이는 곧 시스템의 전체 처리량 붕괴로 이어진다. Llama 3.1 70B와 같은 최신 모델들이 128K 문맥을 지원한다고 선전하지만, 실제 벤치마크에서 128K 풀 문맥을 사용할 때 추론 속도(Tokens/sec)가 급격히 떨어지는 현상은 이러한 KV 캐시의 물리적 점유와 배치 크기 축소에 기인한다.17

3. 메모리 대역폭 장벽(Memory Wall)과 디코딩의 산술 강도 저하

연산 복잡도와 메모리 용량 문제가 해결된다 하더라도(예: 무한한 VRAM을 가진 GPU가 존재한다고 가정하더라도), 트랜스포머는 ’메모리 대역폭(Memory Bandwidth)’이라는 또 다른, 그리고 가장 극복하기 어려운 물리적 한계에 부딪힌다. 이른바 ‘메모리 장벽(Memory Wall)’ 문제이다.

3.1 디코딩 단계의 낮은 산술 강도(Arithmetic Intensity)

컴퓨터 아키텍처에서 어떤 연산 작업이 얼마나 효율적인지를 나타내는 척도로 ’산술 강도’가 사용된다. 이는 메모리에서 1바이트의 데이터를 가져왔을 때, 프로세서가 몇 번의 연산(FLOPs)을 수행하는지를 나타내는 비율이다.19
\text{Arithmetic Intensity} = \frac{\text{Total FLOPs}}{\text{Total Bytes Accessed}}
트랜스포머의 프리필 단계는 거대한 행렬 간의 곱셈(Matrix-Matrix Multiplication)이므로 산술 강도가 매우 높다. 데이터를 한 번 가져와서 수많은 곱셈 덧셈 연산을 수행하므로 GPU의 연산 성능(Compute Capability)이 속도를 결정짓는다(Compute Bound).

반면, 디코딩 단계는 전형적인 행렬-벡터 곱셈(Matrix-Vector Multiplication) 형태를 띤다. 새로운 토큰 하나를 생성하기 위해 GPU는 수십 GB에 달하는 모델 가중치 전체와, 현재까지 누적된 수 GB의 KV 캐시를 HBM에서 칩 내부의 레지스터로 불러와야 한다. 그러나 이렇게 막대한 데이터를 불러와서 수행하는 연산은 고작 벡터 하나(현재 토큰)와의 내적뿐이다.22

긴 문맥 환경에서는 이 비율이 더욱 악화된다. 문맥이 길어질수록 읽어와야 할 KV 캐시 데이터의 양(분모)은 선형적으로 증가하지만, 수행하는 연산량(분자)은 그에 비례해 늘어나지 않는다. 결과적으로 산술 강도는 바닥으로 떨어지며, GPU의 텐서 코어(Tensor Core)들은 데이터가 메모리로부터 도착하기를 기다리며 대부분의 시간을 유휴 상태(Idle)로 보내게 된다. 이것이 바로 ‘메모리 대역폭 제한(Memory Bandwidth Bound)’ 상태이다.15

3.2 GPU 발전의 비대칭성과 병목 심화

문제는 하드웨어의 발전 방향이 이러한 트랜스포머의 디코딩 특성과 엇박자를 내고 있다는 점이다. NVIDIA의 GPU 발전사를 살펴보면, 연산 성능(FLOPS)은 세대마다 폭발적으로 증가해왔지만, 메모리 대역폭의 증가는 상대적으로 더디다.

A100 GPU(80GB PCIe)의 메모리 대역폭은 약 1,935 GB/s인 반면, 최신 H100 SXM5 GPU는 약 3,350 GB/s이다.25 대역폭은 약 1.7배 증가하는 데 그쳤으나, FP16/BF16 연산 성능은 3배 이상 증가했다.27

이러한 불균형은 긴 문맥 추론에서 치명적이다. H100은 A100보다 훨씬 빠르게 연산할 수 있는 능력을 갖췄지만, 디코딩 단계에서는 메모리에서 데이터를 가져오는 속도가 발목을 잡기 때문에 그 엄청난 연산 능력을 전혀 발휘하지 못한다. 실제 벤치마크 결과, 긴 문맥에서의 디코딩 속도는 A100과 H100 간에 스펙 차이만큼의 성능 향상을 보이지 않으며, 이는 두 GPU 모두 연산기가 아닌 메모리 대역폭 한계선에 도달해 있음을 시사한다.29 즉, 트랜스포머 아키텍처 하에서는 더 비싼 GPU를 써도 긴 문맥 처리 속도가 획기적으로 빨라지지 않는 ’수확 체감’의 구간에 진입한 것이다.

4. 실제 벤치마크로 본 효율성 저하의 실체

이론적 분석을 넘어 실제 모델 구동 환경에서의 데이터를 살펴보면, 위에서 언급한 구조적 병목들이 어떻게 성능 저하로 이어지는지 명확히 확인할 수 있다. Llama-3-70B와 같은 최신 대형 모델들은 128K 문맥을 지원하지만, 실제 활용 시에는 문맥 길이에 따른 급격한 성능 저하 곡선을 그린다.

4.1 문맥 길이에 따른 추론 속도(Tokens/sec) 급감

Oracle Cloud와 NVIDIA 등의 벤치마크 데이터에 따르면, Llama-3.3-70B 모델의 경우 문맥 길이가 짧은 구간에서는 초당 40~100 토큰 이상의 빠른 생성 속도를 보이지만, 문맥이 128K에 근접할수록 생성 속도가 급격히 떨어진다.17 이는 앞서 설명한 KV 캐시 로딩으로 인한 메모리 대역폭 포화와 캐시 미스(Cache Miss) 증가 때문이다.

특히 동시 사용자 수(Concurrency)가 증가할 때 이 현상은 더욱 두드러진다. 짧은 문맥에서는 여러 사용자의 요청을 배치 처리하여 높은 처리량을 유지할 수 있지만, 긴 문맥 요청이 섞이는 순간 GPU 메모리가 KV 캐시로 가득 차면서 스와핑(Swapping)이 발생하거나 배치를 강제로 분할해야 하는 상황이 온다. vLLM과 같은 최신 추론 엔진들이 PagedAttention과 같은 메모리 최적화 기술을 도입했음에도 불구하고, 물리적인 대역폭 한계로 인해 긴 문맥에서의 속도 저하는 여전히 해결되지 않은 숙제이다.30

4.2 TTFT와 TPOT의 괴리

사용자 경험 측면에서 긴 문맥 처리는 두 가지 지연 시간을 모두 악화시킨다.

1. TTFT (Time To First Token): 프리필 단계의 O(N^2) 연산 부하로 인해, 긴 프롬프트를 입력하면 첫 글자가 나올 때까지 긴 로딩 시간이 발생한다. 이는 ‘연산(Compute)’ 병목이다.
2. TPOT (Time Per Output Token): 이후 이어지는 텍스트 생성은 KV 캐시 로딩 부하로 인해 토큰 하나하나가 느리게 생성된다. 이는 ‘메모리(Memory)’ 병목이다.

트랜스포머는 이처럼 프리필에서는 연산 장치를 혹사시키고, 디코딩에서는 메모리 대역폭을 혹사시키는 이중고를 겪는다. 이는 하드웨어 설계 관점에서도 최적화하기 매우 까다로운 워크로드 특성이다.

5. 결론: 구조적 한계와 새로운 패러다임의 필요성

지금까지 살펴본 바와 같이, 트랜스포머 아키텍처의 긴 문맥 처리 효율성 저하는 단순히 소프트웨어 최적화로 해결할 수 있는 일시적 문제가 아니다. 이는 ① 시퀀스 길이에 제곱 비례하는 어텐션 연산의 태생적 복잡도, ② 과거 정보를 모두 저장해야 하는 KV 캐시의 선형적 메모리 팽창, ③ 그리고 GPU 발전 속도를 따라가지 못하는 메모리 대역폭의 물리적 한계가 결합된 ’구조적 모순’이다.

KV 캐시 양자화(Quantization), FlashAttention, PagedAttention, GQA(Grouped Query Attention) 등 수많은 엔지니어링 기법들이 이 문제를 완화하기 위해 등장했으나, 이들은 병목의 임계점을 조금 뒤로 미루었을 뿐 근본적인 해결책이 되지 못하고 있다.8 1M 토큰, 10M 토큰 시대로 나아가기 위해서는 O(N^2)의 굴레를 벗어던지고, KV 캐시 없이도 문맥을 효율적으로 압축하여 전달할 수 있는 새로운 아키텍처가 절실하다.

이러한 배경 속에서 등장한 것이 바로 상태 공간 모델(State Space Model, SSM)에 기반한 Mamba 아키텍처이다. Mamba는 추론 시 KV 캐시를 필요로 하지 않으며, 문맥 길이에 상관없이 일정한 메모리(O(1))와 선형적인 연산 시간(O(N))을 보장한다. 이는 트랜스포머가 겪고 있는 메모리 대역폭 병목과 배치 크기 제약 문제를 근본적으로 해결할 수 있는 가능성을 제시한다.33 다음 장에서는 이러한 Mamba 아키텍처가 어떻게 트랜스포머의 구조적 병목을 돌파하고 포스트 트랜스포머 시대의 새로운 표준이 될 수 있는지 구체적으로 살펴볼 것이다.

표 1.3-2 트랜스포머 vs. 포스트 트랜스포머(Mamba) 아키텍처의 긴 문맥 추론 특성 비교

33

6. 참고 자료

1. Reimplementing FlashAttention for performance and giggles - AmineDiro, https://aminediro.com/posts/flash_attn/
2. Attention Complexity: Quadratic Scaling, Memory Limits & Efficient Alternatives - Interactive | Michael Brenndoerfer, https://mbrenndoerfer.com/writing/attention-complexity-quadratic-scaling-memory-efficient-transformers
3. Transformer Inference Estimations: Arithmetic Intensity, Throughput and Cost Optimization, https://www.yadavsaurabh.com/transformer-inference-arithmetic-intensity-cost-and-optimization/
4. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness - arXiv, https://arxiv.org/abs/2205.14135
5. FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning | OpenReview, https://openreview.net/forum?id=mZn2Xyh9Ec
6. ETT: Expanding the Long Context Understanding Capability of LLMs at Test-Time - arXiv, https://arxiv.org/html/2507.06313v1
7. KV Cache and KV Caching. The Hidden Bottleneck of LLM Inference | by Sulbha Jain, https://medium.com/@sulbha.jindal/kv-cache-and-kv-caching-a46acea80fe4
8. Optimizing Inference for Long Context and Large Batch Sizes with NVFP4 KV Cache, https://developer.nvidia.com/blog/optimizing-inference-for-long-context-and-large-batch-sizes-with-nvfp4-kv-cache/
9. KV Cache Size Calculator - LMCache, https://lmcache.ai/kv_cache_calculator.html
10. KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization, https://www.stat.berkeley.edu/~mmahoney/pubs/neurips-2024-kvquant.pdf
11. KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization - arXiv, https://arxiv.org/html/2401.18079v4
12. How much memory context size utilizes, really? : r/LocalLLaMA - Reddit, https://www.reddit.com/r/LocalLLaMA/comments/1f2pc2j/how_much_memory_context_size_utilizes_really/
13. Snowflake AI Research Optimizes Llama 3.1 405B for Efficient AI Deployment, https://www.snowflake.com/en/engineering-blog/optimize-llms-with-llama-snowflake-ai-stack/
14. Mastering LLM Techniques: Inference Optimization | NVIDIA Technical Blog, https://developer.nvidia.com/blog/mastering-llm-techniques-inference-optimization/
15. LLM Inference Performance Engineering: Best Practices | Databricks Blog, https://www.databricks.com/blog/llm-inference-performance-engineering-best-practices
16. KV Cache in Transformers: Memory Optimization | by Mandeep Singh - Medium, https://medium.com/@mandeep0405/kv-cache-in-transformers-memory-optimization-e416a81b3c02
17. Meta Llama 3.3 (70B) - Oracle Help Center, https://docs.oracle.com/en-us/iaas/Content/generative-ai/benchmark-meta-llama-3-3-70b-instruct.htm
18. New AI Inference Speed Benchmark for Llama 3.3 70B, Powered by Groq, https://groq.com/blog/new-ai-inference-speed-benchmark-for-llama-3-3-70b-powered-by-groq
19. All the Transformer Math You Need to Know | How To Scale Your Model - GitHub Pages, https://jax-ml.github.io/scaling-book/transformers/
20. Why Large Language Model inference is memory bound - Alvin Wan, https://alvinwan.com/why-large-language-model-inference-is-memory-bound/
21. LLM Inference Series: 5. Dissecting model performance | by Pierre Lienhart | Medium, https://medium.com/@plienhar/llm-inference-series-5-dissecting-model-performance-6144aa93168f
22. A guide to LLM inference and performance - Baseten, https://www.baseten.co/blog/llm-transformer-inference-guide/
23. LLM Inference Unveiled: Survey and Roofline Model Insights - arXiv, https://arxiv.org/html/2402.16363v5
24. Beyond FLOPs: Understanding IO-Bound vs Compute-Bound in Deep Learning - Medium, https://medium.com/@isanghao/io-bound-or-compute-bound-in-ai-c9c541cd6696
25. NVIDIA A100 PCIe 80 GB Specs - GPU Database - TechPowerUp, https://www.techpowerup.com/gpu-specs/a100-pcie-80-gb.c3821
26. NVIDIA H100 SXM5 80 GB Specs - GPU Database - TechPowerUp, https://www.techpowerup.com/gpu-specs/h100-sxm5-80-gb.c3900
27. Challenges in Deploying Long-Context Transformers: A Theoretical Peak Performance Analysis - arXiv, https://arxiv.org/html/2405.08944v1
28. [D] Why choose an H100 over an A100 for LLM inference? : r/MachineLearning - Reddit, https://www.reddit.com/r/MachineLearning/comments/17hsjdt/d_why_choose_an_h100_over_an_a100_for_llm/
29. Mind the Memory Gap: Unveiling GPU Bottlenecks in Large-Batch LLM Inference - arXiv, https://arxiv.org/html/2503.08311v2
30. LLM-Inference-Bench: Inference Benchmarking of Large Language Models on AI Accelerators - arXiv, https://arxiv.org/html/2411.00136v1
31. Scaling AI Inference Performance with vLLM on AMD Instinct …, https://rocm.blogs.amd.com/artificial-intelligence/scaling-ai-inference/README.html
32. Hardware-Efficient Attention for Fast Decoding - arXiv, https://arxiv.org/html/2505.21487v1
33. Mamba: Linear-Time Sequence Modeling with Selective State Spaces - OpenReview, https://openreview.net/forum?id=tEYskw1VY2
34. How Mamba Beats Transformers at Long Sequences - Galileo AI, https://galileo.ai/blog/mamba-linear-scaling-transformers
35. Mamba: Linear-Time Sequence Modeling with Selective State Spaces - arXiv, https://arxiv.org/pdf/2312.00752
36. Benchmarking Mamba’s Document Ranking Performance in the Era of Transformers - arXiv, https://arxiv.org/html/2403.18276v2
37. Mamba Explained - The Gradient, https://thegradient.pub/mamba-explained/
38. An Empirical Study of Mamba-based Language Models - arXiv, https://arxiv.org/html/2406.07887v1